Date: Thu, 23 Jun 2011 14:43:43 -0400 From: "Osterweil, Eric" <eosterweil@verisign.com> To: Leon =?ISO-8859-1?B?TWXfbmVy?= <l.messner@physik.tu-berlin.de>, <freebsd-questions@freebsd.org> Subject: Re: dnssec with freebsd's resolver(3) Message-ID: <CA29019F.C92A%eosterweil@verisign.com> In-Reply-To: <20110623182346.GD74606@emmi.physik-pool.tu-berlin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6/23/11 2:23 PM, "Leon Me=DFner" <l.messner@physik.tu-berlin.de> wrote: > This mail got only send to Matthew because of bad time of day ;) >=20 > On Wed, Jun 22, 2011 at 10:58:00PM +0100, Matthew Seaman wrote: >> On 22/06/2011 20:02, Osterweil, Eric wrote: >>>=20 >>>=20 >>>=20 >>> On 6/22/11 2:56 PM, "Leon Me=DFner" <l.messner@physik.tu-berlin.de> wrote= : >>>=20 >>>> On Mon, Jun 20, 2011 at 06:17:23AM +0100, Matthew Seaman wrote: <snip> >>>=20 >>> I'm not sure what you mean by "DO processing," but validation requires = a >>> little more than issuing queries w/ the DO bit set (that has been the >>> default in BIND for a while). You need to have the root (or some other= ) >>> trust-anchor configured, and you need to enable DNSSEC validation in yo= ur >>> named.conf. >>>=20 >>> Only after that will you see the AD bit at the stub. >>=20 >> Actually, typically with a correctly configured validating resolver, as >> an end user issuing queries from the system's stub resolver, you'll only >> see responses with data that is either: >>=20 >> -- completely unsigned >>=20 >> -- signed, and that validates correctly >>=20 >> Data that doesn't validate correctly is discarded. Better make sure >> your DNSSEC setup is correctly maintained and updated, or your domains >> may effectively disappear from the net. >>=20 >> "validates correctly" is a function of how your recursive resolver is >> configured: for instance, you will probably want to trust DLV secured >> data until authentication paths up to the root become more prevalent in >> all corners of the DNS. >=20 >=20 > The only thing i want to do at the moment is serve my local zone to my > local clients. If i do >=20 > % dig @dns +dnssec rosa.physik-pool.tu-berlin.de >=20 > i get >=20 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, > ADDITIONAL: 3 >=20 > and also i can see the D0 bit set when looking at the tcpdump. If i now > use the stub resolver through telnet/ssh the D0 bit does _not_ get set > in the query. So there is no way for the recursive NS to supply AD data, > right ? That is correct, sorry. If the stub doesn't request DNSSEC enabled (via th= e DO bit), then the resolver will not return the validation bit. :( I did a little bit of googling, and found these instructions but I have not tried any of this myself: https://www.dnssec-tools.org/svn/dnssec-tools/trunk/htdocs/readme/README.ss= h (Look under the "Requirements" section) There seemed to be a lot of people suggesting that opening bug reports will prompt more attention to this. >=20 > thanks for helping the blind. Not at all! :) Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA29019F.C92A%eosterweil>